home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 49 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.3 KB
  1. Subject: Re: Colour. 
  2. Date: Tue, 31 May 1994 10:03:52 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. In message <Pine.3.87.9405300202.A15807-0100000@undergrad>, you wrote:
  7. >On Mon, 30 May 1994, Warwick Allison wrote:
  8. >> ... colour palette handling by GEM programs ...
  9. >> 
  10. >>     - The standard 16 colours
  11. >>         - They're different under MultiTOS (right?)
  12. >>         - When should a program desire to change them?
  13. >When it's window is topped.
  14.  
  15. ie. when it receives WM_TOPPED?  What if it allows clicks on backgrounded
  16. windows?  Should the program then force a palette-set whenever it is clicked
  17. on?  Not realistic for 256 colour modes.
  18.  
  19. >>         - When should a user desire to change them?
  20. >Expound on this questions please.
  21.  
  22. How much can we allow a user to set there own 16 colours?  For example,
  23. I'm not satisfied with any of the std 16 colours as a colour for my
  24. background window, nor for my std window element colours, nor the colours
  25. available for 3D forms.  So I change them all.  How should programs handle
  26. this (eg. remapping colours used in icons to look for closest match?)
  27.  
  28.  
  29. >>     - Sharing colours
  30. >>         - No point each program allocating its own Purple
  31. >>         - When colours must be changed, it would be nice for
  32. >>            the actual palette change to be minimized (eg. purple
  33. >>            changes to dark purple, not green)
  34. >Are you sure programmers are going to want to put forth that effort?  
  35. >It's much easier to just stick together your palette.  How about someone 
  36. >write a library routine that, given a new palette, sorts them with respect
  37. >to the palette in place?
  38.  
  39. Exactly.  If a library routine is to be provided, then a greater amount
  40. of effort is justified compared to if just a statement of a standard is
  41. required.  For a std, it should be simple, or else people won't follow it.
  42. For a lib routine, extra effort can be employed and the code shared.
  43.  
  44.  
  45. >>     - True Colour emulations
  46. >>         - Some programs use a 5x5x5 or 6x6x6 colourspace, and
  47. >>            these should all be the same space.
  48. >> 
  49. >>     - When to change palettes
  50. >>         - When window is topped?
  51. >Only this one.
  52. >>         - When window is touched in any way?
  53. >In most cases, this would top the window.  Under MultiTOS or others, 
  54. >where you can use the gadgets without topping the window, the palette 
  55. >should NOT be changed to the one for that window... how would you know 
  56. >when to change it back?
  57.  
  58. You can also touch windows without topping them.  And a good thing this
  59. is, too.  Ask any X11 user.  Take for example a screen where 2 applications
  60. are running.  The windows are such that they do not overlap.  The user is
  61. swapping back and forth between the two windows quite regularly (eg. they
  62. are cutting and pasting, with cut occuring using the left button and pasting
  63. by using the right button).  Should the user have to produce an extra click
  64. every time they change applications?  The visual effect of this extra click
  65. under multitos, with window element colours configured to something useful,
  66. would be quite minor.
  67.  
  68. I support clicking on background windows.  So does WINX.  So does MultiTOS.
  69.  
  70.  
  71. >>         - When mouse enters window?
  72. >Too difficult... requires that something watch the mouse pointer.
  73.  
  74. I tend to agree, unless there is some centralized way this mouse-in-window
  75. rather than window-on-top focus can be implemented.
  76.  
  77.  
  78. >Your proposal is sound, however, since not all apps will follow this, and 
  79. >the WM_TOPPED signal is broadcast globally, perhaps apps should set the 
  80. >palette BACK to what it was before when it's window is untopped?
  81.  
  82. This doesn't work.  In fact, the more applications that follow the
  83. scheme, the worse it gets, and the more confusing it gets for the user.
  84. Only if EVERY application follows the protocol will it work... in which
  85. case there is no need to attempt to restore some other application's
  86. palette.
  87.  
  88.  
  89. >For colors, an app should scan all available colors and see what it can 
  90. >match to.  When changing the palette, it should favor using those above 15.
  91.  
  92. Match exactly?  That won't work unless you adopt the X11 approach of naming
  93. colours.  The colour space is too large otherwise (ie. WHICH purple?).
  94.  
  95.  
  96. >Since GEM is too free about this, this one is going to be tough for us to 
  97. >work out, especially since no-one before will have followed these rules, 
  98. >yet we'll have to tollerate their apps.
  99.  
  100. Yes.  Whatever the solution, older apps must be catered for in some way.
  101. Fortunately, many older applications where monochromatic.
  102.  
  103. --
  104. Warwick
  105.